This invention relates to software architecture and more particularly to a software architecture for web-based systems.
To develop a web site, web pages are created in a hyper-text markup language (HTML) and stored on a server connected to the Internet and some mass data storage device such as a database. Web hosting companies develop the software and maintain the hardware that provide web-based services for a client, or tenant. Web-site specific applications are also created and customized for each tenant""s specific needs. In addition to applications, tenants are likely to need distinct versions of each web page for each type of browser the page is likely to encounter because web browsers are incompatible. For example, one version of a page may be necessary for Microsoft Explorer and another for Netscape Navigator. Moreover, different versions of pages will be necessary for wireless telephone browsers as opposed to browsers designed for conventional computer display screens.
Typical web-hosting services have multiple tenants, each with different needs. It is often the case that some tenants actually have conflicting needs so that the system has to be flexible enough to handle the different needs between tenants and agile enough so that each tenant only uses the logic necessary to do its own processing. This balance is extremely difficult to achieve and so it is not uncommon that web-based systems go through large amounts of logic, performing useless verification processes.
With mobile devices that can access the web, more problems are encountered with publishing web site content. Support for devices with screens of varying size must be provided in addition to changing pre-existing server pages designed for a web browser, which calls for reconstructing the logic behind web pages.
Within every system, there are business rules, or logic, that represent constraints and policies to govern how system information can be modified or accessed while safeguarding the integrity of the application""s data. As a system grows, more rules are added and pre-existing rules changed, increasing complexity and making it harder to decipher processing logic when modifying the logic at a later time.
As software is developed and built for multi-tenant services, the system is exposed to the combined changes of all tenants. The information model, which is the sum of all information needed to support all the system users, must be adapted to each specific user""s needs in viewing the information who work for different departments, each with a different view of the business world. Information models are typically modeled to suit the initial needs of a system when it is first built. As each new feature or departmental view needs to be supported there is usually a need to change the information model.
However, developers tend to resist making changes to the information model. This often results in using part of the information model for purposes it was not designed. Although this may be the most expedient solution, it almost inevitably causes unexpected complications. For example, assume that a user needs to track the lifecycle of a high priced item, such as a car. If there is no such object in the information model of the system, an object that does have lifecycle support, such as a project object, may be modified to view as a car by copying the project user interface and modifying it accordingly. Alternatively, the developer might use the project object without modification, for example, by introducing a special project-type code, which is not part of the information model but is introduced into the code using the information model. In the event the project object is overhauled, the entire support for the car object would have to be reconstructed. Such changes are particularly troublesome if the database is used by multiple tenants (using the same instance), or if the information model is part of the software delivered to the customer (requiring a time consuming software update). But this was the problem the developer was trying to avoid in the first place by using the information model for purposes it was not designed for rather than modifying the information model.
In the prior art systems, there is no, or poor separation of concern between the structure of information and the structure of its use. In the project example discussed above, although the information structures (Car and Project) were almost identical, the implementation included project semantics in the information model. In other words, each implementation included structures that were specific to each particular application. The best solution would have been an abstract information model. Unfortunately, when using an xe2x80x9cabstract model,xe2x80x9d the developer writing the business logic must use the structures of the model which, because they are xe2x80x9cabstractxe2x80x9d, necessarily have abstract and difficult names. Therefore, the developer cannot express the logic in well-known terms. Moreover, because the abstract structures are generic to multiple uses, the developer may need to use several layers of xe2x80x9cmental indirectionxe2x80x9d to obtain the desired result. Therefore, while an abstract information model is very flexible, its abstract nature makes the resulting logic difficult for users and subsequent developers to understand. Separation is needed between the need for an information model capable of holding all of the information in a flexible (adaptable and changeable) way, and the need for the users of the information to understand and work with the information.
The Ovum Model (Engineering for Change: The Ovum six-layer reference model, Neil Ward-Dutton, February 1997), incorporated herein by reference, attempts to address the problems of the prior art by providing a six layer architecture. The Ovum Model, however, merely recites a collection of requirements, without any description or indication of how its architecture should be implemented.
In accordance with an embodiment of the present invention, a system for transferring information between a user interface and a database over a global information network such as the Internet is provided. A plurality of user interfaces are located on a plurality of user computers. In this regard, the user interfaces are implemented on a browser using a mark up language such as HTML. The database is a relational database residing on a second computer, and is accessed by the user interface via a global information network such as the Internet. In accordance with the present invention, the relational database is accessed through four intermediate processing layers: an interaction layer, an application layer, a business object layer, and an information model layer, each located on a second computer, with the information model layer logically adjacent to the database, and the interaction layer logically adjacent to the user interface operating on the browser. It should be noted that the xe2x80x9csecond computerxe2x80x9d could be a single computer which implements the interaction layer, an application layer, business object layer, information model layer, and relational database, or could comprise multiple computers located in a single or multiple locations, connected, for example, via a LAN or WAN. Preferably, the information at each layer of the system above the database layer is in a form which is immediately renderable on a user interface. Most preferably, the information in each of these layers is in the form of an XML document.
As explained in more detail below, the use of these four intermediate layers provides a separation of concern for developers of applications of the information in the database and is particularly useful in supporting multiple tenancies on the relational database. For example, the accounting department, human services department, production department, and research and development department of a first company will have the need to access overlapping data in the relational database, but each will need this information for a substantially different purpose. The corresponding departments of a second company will have needs which are similarly overlapping, yet different, from both each other and the corresponding departments of the first company. Through the use of the present invention, each department can view the relational database in its own specific context, and can modify the appearance of the database to suit its particular needs without affecting the other tenants (e.g. other companies) or of different departments within a single tenant.
In accordance with this embodiment, the information model layer maintains a first relational tree of the information in the relational database. This relational tree appears as a plurality of entities in a mark up language (such as XML) to the business object layer and the information in the relational database is accessible via the relational tree. In the context of the present invention, the nomenclature of xe2x80x9cappearing as entities . . . in a mark up languagexe2x80x9d means that the information model is accessed by the next higher layer as if it were a mark up language document such as an XML document. In this regard, the xe2x80x9centityxe2x80x9d could either be a mark up language document (such as an XML document) or a process which acts as a proxy for a mark up language document. In any event, from the perspective of the business object layer, the information model layer is a set of mark up language documents, and is, in effect, the data. Preferably, the information model entities are XML documents which include item elements which define the attributes of the entity, and relationship elements which define relationships to other entities and to the underlying relational database.
The business object model layer includes a plurality of business object instances, each of which maintains a second relational tree corresponding to a portion of the first relational tree. The second relational tree appears as a plurality of entities in a mark up language (such as XML) to the application layer.
Taking the example mentioned above with regard to various departments in a company, the information model layer would provide an objective view of the information in the relational database, whereas the business object instances would provide subjective views which relate to specific intended uses. For example, the information model might be organized as follows:
In contrast, a business object instance which was concerned with product deliveries might organize the same information as follows:
In this manner, each business object instance can organize and label the data in a manner which is more useful to its particular uses, without requiring any changes to the information model layer. Preferably, the business object layer is comprised of a plurality of business object instances, each of which is defined as an XML document. Preferably, each business object instance implements its relational tree using one or more of a composite element, a set element, an instance element, and an item element. An item element is an entity which has a value, whereas the set elements, composite elements and instance elements define structures. An instance element corresponds to a leaf on the relational tree. In other words, an instance element holds item elements. For example, a person instance may have an item called xe2x80x9cBirthdayxe2x80x9d, and for a particular Person(Joe Smith) the value of the Birthday item is xe2x80x9cMar. 8, 1959xe2x80x9d. In this example, the instance element represents a Person(Joe Smith), and a set element could refer to a plurality of instance elements (e.g. Person (Joe Smith, John Doe, Mary Jane)). A composite element represents a structure, and is a sub-element of the set element and instance element. In this regard, an instance element includes a single composite element, whereas a set element includes a plurality of composite elements. The composite element includes item elements and may include set elements, and instance elements (which may in turn contain other composite elements). As discussed in more detail below, each of these elements includes xe2x80x9cattributesxe2x80x9d (such as the elements name and its relationship (if any) to a target object on the first relational tree) and may include sub-elements (e.g., an instance element may include an item sub-element).
The application layer includes a plurality of application object instances, each of which includes an application object definition which specifies one or more methods and business object instances available to the application object. The methods are operable to implement behavior requested by a user interface using information from the relational database accessed through the specified business object instances. The application layer appears as a plurality of entities in a mark up language to the interaction layer.
The interaction layer includes a plurality of interaction objects, each interaction object including information identifying an application object and information specifying a manner in which requests from a user interface are to be processed for transmission to the application object and in which responses from the application object are to be transmitted to the user interface. The interaction layer appears as a plurality of entities in a mark up language to the user interface. As mentioned above, the user interface preferably includes a browser located on a computer, and is displayed as a plurality of web pages generated from a plurality of entities in a mark up language (such as HTML or XML).
In accordance with another embodiment of the present invention, a database system is provided in which all information in the database is maintained in a form which is immediately renderable on a user interface. In accordance with this embodiment, a method of organizing data includes providing a first plurality of data entities and a second plurality of data entities. Each of the second plurality of data entities is generated by processing at least one of the first plurality of data entities and each of the first and second plurality of data entities are immediately renderable to a human via a user interface.